Websydian v6.1 online documentationOnline documentation - WebsydianExpress v3.5

ExtAssociationSelect

Scoped name

WSYEXTJS/ExtAssociationSelect

Note that this abstract function is placed in the WSYEXTJS model.

Purpose

The entity is designed to make it possible to maintain association entities (entities implementing a relation between two primary entities - Owner and Owner2).

Inheriting from this entity will add a ProcessEntryPoint function that scopes a Selector function.

This Selector function can be used to assign several records from Owner2 to one record from the Owner entity.

This means that you must be able to call the Selector function with the unique identification of the Owner record you want to assign Owner2 records to.

As shown in the example page below, the selector function contains three primary regions:

  1. A detail region showing detailed information about the Owner record
  2. A grid region showing the selectable records of Owner2
  3. A grid region showing the currently selected records of Owner2

When the user selects a record in the left grid and presses "Add", the record is removed from the left grid and loaded in the right grid. At this point, the association record is created.

If the user selects a record in the right grid presses "Remove", the record is removed from the right grid and loaded in the left grid. At this point, the association record is deleted.

If there already exists association records for the Owner record when the page is loaded, these records will be shown in the right grid and not in the left. So the content of the right grid will always show the Owner2 records that has an association to the current Owner record.

Usage

The base definitions for an association entity is as follows:

Source Object Verb Target Object
MyAssociationEntity is a ENT WSYEXTJS/ExtAssociationSelect
MyAssociationEntity replaces ENT

...by ENT

Owner

MyOwner

MyAssociationEntity replaces ENT

...by ENT

Owner2

MyOwner2

The definitions are much the same as for the association patterns in Plex's foundation library. This means that if you already uses one of these patterns, you will often just have to specify the inheritance from ExtAssociationSelect.

In most cases, you will want to specify an alternative sort order of the left grid showing the selectable records.

As this is loaded with records from the Owner2 entity, you must replace the Owner2.Fetch view with the view from MyOwner2 entity that defines the order in which you want to list the records.

You must also replace the Owner2.Fetch.BlockFetch function with a BlockFetch function scoped by this view. Note that this function must inherit either from a BlockFetchRRNWrapper or from a WsyStatelessBlockFetchRRN function.

The PageGenerator removes any records from the left grid if they are present in the right grid (see the subroutine "Set row usage" in the Selector.ChildGridSelectable function). This means that you do not have to remove the records in your BlockFetch - you can just return all the records that should be available for selection.

In most cases, you will replace this on either the selector function or on the scoped ChildGridSelectable function.

Source Object Verb Target Object
MyAssociationEntity.Selector replaces VW

...by VW

Owner2.Fetch

MyOwner2.MySortView

MyAssociationEntity.Selector replaces FNC

...by FNC

Owner2.Fetch.BlockFetch

MyOwner2.MySortView.BlockFetchRRN

In many cases, the number of selected records (shown in the right grid) will be so small that a sort isn't necessary.

However, in some cases you might want to sort the content of the right grid as well.

This can be a bit more challenging, as the records shown in this grid actually are from the association entity.

If you have not done anything except the replacement described above, the association entity will only contain the primary keys of MyOwner and MyOwner2 - which rarely will be of much used for sorting the grid records.

If you want this sort to occur, you have several options - e.g. using virtual fields on the association entity and then specifying a sort view based on these fields. As your choice will be highly dependent on the storage variant you are using, no particular implementation of the sort will be described here.

Redefining the size of the Selector function

The selector function is placed in a modal pop up window. It is important that you specify a suitable size for the window so that it fits the content of the three sections of the page.

In the wsyproperties source code scoped by the Selector function you will find the default size definitions for the pop up window. Override the size by changing the values specified for with and height.

Calling the selector function

The top function ( ExtAssociationSelector) is a business process that calls the selector function. It calls the selector function and maps the input (the Owner key) with the webinput variable. By using this business process, you can call the selector using a deep-link with parameters or a menu service with parameters so the key is available in the request.

However, in most cases you will want to call the selector from another page in your application using an ExtEventHandler. This EventHandler must have the primary key of the Owner entity in Webinput and in Hidden.

It must be placed on a page, where the primary key fields of the Owner records is available in WsyDetails (if the event is a detail event) or in WsyGrid (if the event is a grid event). In the EventHandler, you must call the Selector function - map the Restrict parameter with Webinput.

As the ExtAssociationSelect pattern is designed to work in a pop-up window, you must let your EventHandler inherit from ExtEvetHandlerPopUp (detail event) or from ExtGridEventHandlerPopUp - or specify wsyextpopupevent/wsyextpopupgridevent in the wsyeventtype source code scoped by the EventHandler.

Special considerations

If you call the business process using a deep-link with parameters, you must be aware that as for all other deep-links, the parameters are not protected by a signature. You must either ensure that the parameters are validated - or that the functionality should be available for all users, irrespective of the key specified for the Owner entity.

More information